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BACKGROUND OF THE INVENTION 
Field of the Invention 

This invention relates generally to a multi-source order request servicing 

system and more particularly relates to a system and method for receiving, servicing, 
and fulfilling order requests which supports at least one order request management 
system sources. The multi-source order request servicing system obtains and provides 
a complete, accurate and timely response to each order request by integrating 
information from multiple sources. 
Description of the Related Art 

In the stream of commerce, numerous commercial transactions occur between 
multiple parties to enable a manufacturer to provide an item to a customer. 
Historically many, if not all, of these commercial transactions were insular and 
discreet, with respect to the other commercial transactions in the stream of commerce. 
Each involved business traditions and customs uniquely tailored for the commercial 
transaction at hand. These traditions and customs between merchants in the ordinary 
course of business evolved over centuries of dealing. As a result, the traditions and 
customs for any given commercial transaction often differ markedly from those 
associated with other commercial transactions. So pervasive were these traditions and 
customs that the first successful attempt to bring uniformity to commercial 
transactions did not occur until the 1950s, with the creation of the Uniform 
Commercial Code. To this day, however, the Uniform Commercial Code has not 
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been adopted by every state in the Union. Uniformity in commercial transactions is 
lacking. 

The advent of the Internet has intensified the need to bring uniformity with 
respect to certain aspects of commercial transactions. The Internet typically includes 
a plurality of users employing client terminals to order request information from a 
remote server computer. The remote server computer may then collect information 
from a variety of other computer systems to fulfill the user's order request, and 
presents the information to the user. To facilitate the transfer, the client terminals 
have a web browser that presents a web page containing information obtained from a 
server, and web servers store information using a standard protocol. One popular 
collection of servers uses a standardized Hypertext Transfer Protocol (HTTP) to 
provide information and is known as the "World Wide Web." 

The information is typically presented as web pages written as text with 
standardized formatting and control symbols known as Hypertext Mark-up Language 
(HTML). HTML provides basic document formatting and allows a server to specify 
"links" to other servers and files. Use of an HTML-compliant browser involves 
specification of a link via a Uniform Resource Locator (URL). Upon such 
specification, the user's client terminal makes a TCP/IP order request to the server 
identified in the link and receives an HTML file that is interpreted by the browser. 
An electronic HTML document made up of one or more web pages may be displayed 
on the client's terminal. 

A drawback with the available technology employed to take advantage of the 
Internet concerns the diversity of computing systems involved in any given 
commercial transaction. Commercial transactions do not have a standard protocol 
which every computer system involved in a commercial transaction can understand. 
Ensuring compatibility between the various computer systems of the parties involved 
in the commercial transaction has proven daunting. The compatibility problem is 
exacerbated when attempting to perform commercial transactions involving the 
myriad of contractual rights and obligations that may exist between the parties. 

A merchant, such as a merchant using the Internet to sell its goods and 
services, faces substantial challenges in obtaining information from the various parties 
involved in a commercial transaction. For instance, the merchant may not be the 
manufacturer of the goods it sells, and fulfilling orders for goods may involve 
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complex supply and distribution chains including many other business partners 
("suppliers")* Furthermore, the merchant may purchase goods or services from a 
supplier that does not directly supply the goods or services, but that is an intermediary 
business having its own supply and distribution chain. Information from all 
businesses in the supply chain involved in fulfilling an order would enable the 
merchant to provide complete, timely, and accurate responses to order requests from 
customers. 

Accurate order information is likely stored in the suppliers' "order request 
management systems", which are order request management systems that deal with 
managing orders for goods and services. Each supplier's order request management 
system in a supply chain is a potential source of order information. However, these 
order request management systems may be incompatible with the order request 
management system used by the merchant. The merchant desires access to timely and 
accurate order information from its suppliers' order request management systems. 
What is needed is a multi-source order request servicing system that allows the 
merchant's systems to integrate information from other parties' order request 
management systems to obtain complete, timely, and accurate information. An "order 
request servicing system" is a type of multi-source order request servicing system that 
deals with integrating information about orders from multiple sources in the supply 
chain, including suppliers' order request management systems. 

A merchant may also prefer that its complex supply and distribution chain be 
invisible to its customers, so that the merchant appears to be directly selling to its 
customers using a "virtual direct sales model." To use a virtual direct sales model, the 
merchant desires timely and accurate information from the multiple sources in all 
levels of the supply chain. The multiple sources in all levels of the supply chain 
include the order request management systems of the lower-level suppliers that supply 
goods or services to an upper-level supplier or reseller in a multi-level supply chain. 

In a virtual direct sales model, the merchant integrates the order status 
information from multiple sources in the supply chain to present a complete response 
to an order from its customers. With accurate and timely integrated information, the 
merchant can serve as the single point of contact with its customers, hiding the fact 
that the merchant uses a complex supply chain to fulfill customer orders. 
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Most order request management systems do not address the problems of 
dealing with a complex chain of suppliers and do not provide the capability to 
transmit and receive information from a variety of supplier computer systems even in 
a single-level supply chain. Support for obtaining information from suppliers in a 
5 multi-level supply chain is not generally available. Existing order request 

management systems do not provide the complete, timely, and accurate information 
needed to enable a virtual direct sales model. 

In addition, most order request management systems are custom- written or 
modified to deal with the commercial transactions and business relationships of a 
10 particular business. These systems are usually not capable of managing orders for 
more than one business. In particular, these order request management systems are 
~ usually not capable of respecting the business relationships of each of a plurality of 

tf? businesses sharing an order request servicing system. Sharing multi-source order 

request servicing systems such as an order request servicing system is especially 
15 desirable in the Internet environment, where merchants may not have or wish to 

ijl expend the resources to develop their own multi-source order request servicing 

CP 

B systems. 

M What is needed is a multi-source order request servicing system that allows the 

0 merchant's systems to communicate with multiple sources, including other parties' 

1 s ! 

q 20 order request management systems. The multi-source information integration and 
P routing system to integrates complete, timely, and accurate information from the 

multiple sources in response to a order request such as an order from a customer. 
The multi-source order request servicing system should be capable of managing order 
requests involving multiple businesses in a complex supply chain, while respecting 
25 the business relationships of each business within the supply chain. Furthermore, the 
order request servicing system should be flexible enough to be used by an 
intermediary information integrating organization to integrate information for more 
than one merchant. The multi-source order request servicing system should enable a 
merchant to use a virtual direct sales model to its customers. Finally, the multi-source 
30 order request servicing system should be capable of being chained to other multi- 
source order request servicing systems to enable direct access to all suppliers' order 
request management systems in a multi-level supply chain. 
SUMMARY OF THE INVENTION 
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One embodiment of the present invention includes a transaction processing method 
utilizing an order request servicing system for routing order requests to one or more 
order request management systems ("ORMSs") and integrating respective ORMS 
data, the method comprising: 
5 receiving an order request; 

selecting at least one ORMS from the plurality of ORMSs based on the order 

request; 
if only one ORMS is selected: 

processing the order request to generate a processed order request; 
10 transmitting the processed order request to the selected ORMS; 

receiving ORMS data associated with the transmitted processed order 

request from the selected ORMS; and 
processing the ORMS data to generate first processed ORMS data; 

and 

15 if a plurality of ORMSs are selected: 

processing the order request to generate a plurality of processed order 
requests; 

M for each of the processed order requests, transmitting the processed 

iii 

O order request to one of the selected ORMSs; 

Id 

~ 20 receiving respective ORMS data from each of the selected ORMSs, 

p wherein ORMS data from each of the selected ORMSs is 

associated with the processed order request transmitted to each 
selected ORMS; and 
processing the received plurality of ORMS data to generate second 
25 processed ORMS data. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Features appearing in multiple figures with the same reference numeral are the 

same unless otherwise indicated. 
30 Fig. 1 shows an embodiment of an information integrating network as an order 

servicing network, including multi-source order request servicing systems embodied 
as order request servicing systems and order request management systems embodied 
as order request management systems. 
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Fig. 1 A is a block diagram of a computer system. 

Fig. 2 shows an overview of the operation of the order request servicing 
system of Fig. 1. 

Fig. 3 shows the environment in which the order request servicing system of 
Fig. 1 operates. 

Fig. 4 shows an information flow of the order request servicing system of Fig. 
3 in response to receiving a order request in the form of an order. 

Fig. 5 is a detailed block diagram of one embodiment of the order request 
servicing system. 

Fig. 6 shows a flowchart of the operation of the Analyze Order 
request/Response and Create Necessary Transactions module of the order request 
servicing system of Fig. 5. 

Fig. 7 shows a flowchart of the Analyze Order step of Fig. 6. 

Fig. 8 shows a flowchart of the Analyze Order request/Response for Order 
Status step of Fig. 6. 

Fig. 9 shows a flowchart of the Analyze Provider Order Status step of Fig. 6. 

DETAILED DESCRIPTION 

The following description of the invention is intended to be illustrative only 

and not limiting. 

An information integrating network enables members of the network to share 
integrated information of interest to several parties involved in business relationships. 
An example of an information integrating network is an order servicing network, 
which enables parties involved in the supply chain for an order to share information 
about the order. One skilled in the art will recognize that the system and method 
described for servicing orders can be used for servicing other types of order requests. 
Note that any references to "transactions" transmitted to an order request management 
systems may also be referred to a processed order request. Note also that any 
references to "transactions" from an order request management system may also be 
referred to as processed order request management system data or order request 
management system data. 

Fig. 1 shows an embodiment of an transaction processing system having an 
order requests servicing network, including order request servicing systems embodied 
as order request servicing systems and order request management systems embodied 
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as order request management systems. In this embodiment, the components of each 
network communicate using the Internet. An order servicing network 130 is used by 
merchants selling and distributing items to receive, manage, and fulfill orders. An 
"order" is an example of a order request from a buyer, hereinafter "customer," to 
purchase at least one item from a seller. The term "item" is used herein to include 
both goods and services. 

The order servicing network 130 can respond to a variety of order requests 
concerning orders. An order is a type of order request, and an order status (such as 
"item shipped" or "item on backorder") is a type of response to an order request. The 
term "order request" also includes a order request to view information related to 
orders, such as a catalog, where the response is to present the catalog to the customer. 
A order request may be a order request to return an item previously ordered, where 
responses are to credit the customer's account for the returned item, notify the 
customer of the credit, and transmit the item back to inventory. Generally, other types 
of order requests include a change to a previous order request, the response being to 
change the order request and respond accordingly to the changed order request; a 
cancellation of a previous order request, the response being to cancel the order request 
and any work in progress to respond to the order request; and a order request for the 
status of a previous order request, where the response is a order request status. Many 
other types of order requests are included in the term "order request" as used herein, 
and the corresponding responses are included in the term "order request response" as 
used herein. One skilled in the art will recognize that the system and method 
described for servicing orders can be used for servicing other types of order requests. 

In order to represent the complex relationships in a multi-level supply chain, 
four different types of parties are used herein. The parties which may be involved in 
transmitting, managing, and fulfilling a order request include a customer, a client, an 
order request servicing organization, and one or more fulfillment partners. An order 
servicing organization is a type of a order request servicing organization that deals 
with orders. The customer submits an order (a order request) to the client, which 
submits an order (a order request) to the order servicing organization, which in turn 
uses fulfillment partners to fulfill the order (a order request response). 

Each business in a supply chain may fulfill one or more roles in a supply 
chain, and a single business may fulfill one or more roles. For instance, a client 
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serves both buyer and seller roles, because the client buys from a fulfillment partner 
and sells to the customer. As an example of a business fulfilling multiple roles, the 
customer and the client may be the same business, and will probably fulfill the buyer 
role. Similarly, the client and the order servicing organization may be the same 
business, serving as either a buyer, a seller, or both. When the order servicing 
organization and the client are not the same business entity, the order servicing 
organization may act as an intermediary to service orders for many different clients. 

Fulfillment partners include suppliers, resellers, distributors, and 
manufacturers that have a contractual relationship to a client. As an example of the 
four-party scenario above, a fulfillment partner sells items to an order servicing 
organization, which in turn sells the items to the client, which ultimately sells the item 
to the customer. Fulfillment partners may also include the order servicing 
organization itself or its divisions when the order servicing organization uses its own 
resources to fill an order. In a multi-level supply chain, a fulfillment partner may 
have its own complex supply chain involving multiple fulfillment partners of its own. 

The parties involved in an order servicing network 130 are associated through 
relationships. For example, a client, order servicing organization, and fulfillment 
partner may have the following type of relationships: 

• An ordering relationship between the client and a fulfillment partner, 
indicating that the client has a business relationship with the fulfillment 
partner; 

• A pricing relationship between the client and the fulfillment partner. When 
the client and the order servicing organization are not the same business, a 
pricing relationship may exist between the client and the order servicing 
organization, and between the order servicing organization and the fulfillment 
partner; 

• An availability relationship between the fulfillment partner and the client; 

• An order fulfillment relationship between the fulfillment partner and the 
client; and 

• A catalog relationship between the fulfillment partner and the client. 

A customer 102, which may be a person or a business, transmits a order 
request, such as an order, to the client using a client interface 104 to a client system 
105. Examples of a client interface 104 include a kiosk, a web storefront, an Internet 
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terminal, or any other user interface to a client system 105. The client system 105 then 
transmits the customer 102 order request to the order servicing organization's order 
request servicing system 110. An example of an order request servicing system 1 10 is 
the OrderServer™ product by pcOrder.com, Inc. 

A fulfillment partner is selected by the order request servicing system 1 10 to 
fulfill a portion or all of the order (order request). A selected fulfillment partner is 
called a provider. An order request management system 120 is a fulfillment partner's 
computer system for receiving, processing, and fulfilling order requests in the form of 
orders. An order request management system 120 may include an order request 
servicing system 110. 

An order servicing network 130 includes an order request servicing system 
110 and one or more order request management systems 120. An order servicing 
network 130 preferably includes a plurality of order request management systems 120 
from which to select to fulfill a order request. 

While the Internet is used herein as an example of how the order servicing 
network 130 is connected, other information networks may also be used. For 
example, the components of an order servicing network 130 could be connected using 
direct links such as Tl or ISDN lines, through satellite or cellular networks using 
wireless technology, or through a local data transport system such as Ethernet or 
token ring over a local area network. In addition, although the order servicing 
networks 130 shown in Fig. 1 do not overlap, order servicing networks 130 may 
overlap geographically and by including common order request servicing systems 110 
or order request management systems 120. 

The order request servicing system 110 analyzes a order request from the 
client system 105, may create transactions to be completed by an order request 
management system 120, may create transactions for other systems 202, and, if 
transactions are created, transmits the transactions to the appropriate computer 
systems. 

If the order request from the client is an order, the order request servicing 
system 110 analyzes the order to identify items ordered and selects at least one order 
request management system 120 from the business relationships of the client using the 
client's routing rules. If more than one order request management system 120 is 
selected, the order request servicing system 110 prepares a provider order containing 
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at least one item for each selected order request management system 120. The order 
request management system 110 receives the provider order, processes the order, and 
provides the at least one item to the customer. During the entire process, the order 
request servicing system 110 integrates all order information from the providers' 
5 order request management systems, providing a single integrated source of complete, 
accurate, and timely order status information. A single integrated source of order 
information is possible in an order servicing network despite the fact that a complex 
network of suppliers, each managing its own orders with its own order request 
management system 120, is involved in actually filling the order. 
10 Fig. 1 shows several client systems 105, which enable a customer to transmit a 

order request, such as an order, which the client system 105 communicates to the 
order request servicing system 110. A client system 105 of an order request servicing 
yn system 110 may take any of the following forms: 

r? • Any computer system with a client interface 104 that is used by customers 102 

ffl 15 to transmit order requests, such as orders, to an order request servicing system 

m 110. Examples of a client interface 104 include a kiosk, a web storefront, an 

* ' Internet terminal, or any other user interface to a client system 105. The client 

system 1 05 transmits the order request over a network (via an EDI gateway or 
§ an XML gateway) to the order request servicing system 110. 

™ 20 • an order request servicing system 110 recursively calling itself to transmit an 
3 order. In this case, a single order request servicing system 110 serves as both 

a client and a server; or 
• a first order request servicing system 110 calling a provider's order request 
management system 120, where the provider's order request management 
25 system includes a second order request servicing system 110. The first order 

request servicing system 110 acts as a client system 105 of the second order 
request servicing system 110. This architecture allows a client or order 
servicing organization to chain multiple fulfillment partners, each with its own 
complex supply chains, to form an integrated source of order information. 
30 The client system 105 provides a order request from the customer, such as an order, to 
the order request servicing system 110. 

One of the strengths of the order request servicing system 1 10 is that it can 
communicate with a variety of provider order request management systems 1 20. The 
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order servicing organization provides the order request servicing system 110 with an 
implementation of an interface to each order request management system 120, which 
enables the order request servicing system 1 10 to communicate with the order request 
management system 120 as if the two systems were one. 

The term centralized is used to describe the order request servicing system 110 
not because of its physical location, but because communications between client 
systems 105 and order request management systems 120 pass through the order 
request servicing system 110. The centralized nature of the communications provides 
the client with a single integrated source of order information, the order request 
servicing system 110. The order servicing network 130 of order servicing 
organizations and fulfillment partners is completely transparent to the customer. This 
transparency enables the client to present a virtual direct sales model to its customers. 
In this situation, the order request servicing system 110 serves as a hub of an order 
servicing network 130. 

An order servicing organization may use a single order request servicing 
system 1 10 to service the orders of multiple clients. The order request servicing 
system is designed to enable different business relationships and business rules to be 
followed for fulfilling orders of each client. This design enables complex supply 
chains to be modeled and provides the flexibility needed to enable the virtual direct 
sales model. Again in this situation, the order request servicing system 110 serves as 
a hub of the order servicing network 130. 

A provider's order request management system 120 may include, but is not 
required to include, an order request servicing system 110. If the provider's order 
request management system 120 includes an order request servicing system 110, then 
the provider's order request servicing system 1 10 is a spoke in the order servicing 
organization's order servicing network 130. The flexibility of the design of the order 
request servicing system 110 allows the order request servicing system 1 10 to serve as 
either a hub or a spoke in an order servicing network 130. The capability to chain 
multiple order request servicing systems 110 together allows very complex supply 
chains to be modeled and enables a virtual direct sales model. 

Fig. 1 A is a block diagram of a computer system, such as client systems 105, 
order request servicing systems 110, and order request management systems 120 
shown in Fig. 1. Figure 1 A depicts several computer systems 14. Computer systems 
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14 may communicate with one or more other computer systems 14 via a network 12, 
such as the Internet. In one embodiment, each computer system 14 includes one or 
more system buses 22 placing various components of the system in data 
communication. For example, system bus 22 allows data communication between 
processor 24 and both a read only memory (ROM) 26 and random access memory 
(RAM) 28. 

The ROM 26 contains among other code, the Basic Input-Output system 
(BIOS) which controls basic hardware operation such as the interaction with 
peripheral components such as keyboard 34. Applications resident with a computer 
system 14 are generally stored on and accessed via a computer readable medium 32, 
such as a hard disk drive, optical drive, floppy disk drive, compact disk, or other 
storage medium. Additionally, applications may be in the form of electronic signals 
modulated in accordance with the application and data communication technology 
when accessed via network 12. 

The RAM 28 is the main memory into which the operating system and 
application programs are loaded and generally affords at least 32 megabytes of 
memory space. Through data communication on system bus 22, memory 
management chip 36 controls direct memory access (DMA) operations. DMA 
operations include passing data between the RAM 28 and the mass storage memory 
32. Also in data communication with the system bus 22 are various I/O controllers: a 
keyboard controller 38, a mouse controller 40 and a video controller 42. The 
keyboard controller 38 provides a hardware interface for the keyboard 34, the mouse 
controller 40 provides the hardware interface for a mouse 46, or other point and click 
device, and the video controller 42 provides a hardware interface for a display 48. 

A modem 50 or network circuitry (not shown) enables networked computer 
systems 14 to communicate data over a network 12 via any of various data 
communication technologies such as digital subscriber lines ("DSL"), asynchronous 
DSL, ISDN, or ordinary telephone lines. The operating system 52 of the computer 
system 14 may be WINDOWS NT, UNIX, or any other known operating system. 
The RAM 28 also supports a number of Internet access tools, including, for example, 
an HTTP-compliant Web browser having a JavaScript interpreter, such as Netscape 
Navigator 3.0, Microsoft Explorer 3.0, and other similar browsers. 
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Those skilled in the art will appreciate that the computer system shown in Fig. 
1 A encompasses all types of computer systems including, for example, mainframes, 
minicomputers, workstations, servers, personal computers, Internet terminals, network 
appliances, notebooks, palm tops, personal digital assistants, and embedded systems. 
Computer system 14 may include additional or fewer components than shown in Fig. 
1 A and described herein. 

Fig. 2 shows an overview of the operation of an embodiment of a multi-source 
order request servicing system, the order request servicing system 110. As shown in 
Fig. 2, a order request such as an order flows from a customer to a client system 105 
through an order request servicing system 1 10 to an order request management system 
120. A response to the order request flows back from the order request management 
system 120 through the order request servicing system 110 and client system 105 to 
the customer 102. 

For example, a customer 102 uses a client system 105 to transmit a order 
request, such as an order, to the order request servicing system 110. Upon receiving a 
order request from the client system 105, the order request servicing system 110 
analyzes the order request and may transmit a transaction to an order request 
management system 120. If the client transmits an order, the order request servicing 
system 110 transmits at least one transaction in the form of a provider order to at least 
one order request management system 120. When the order request servicing system 
110 receives a response to a order request, such as a provider order status, it analyzes 
the information to determine whether to transmit additional transactions to the order 
request management systems 120. Order request servicing system 110 also 
determines whether to transmit additional notification transactions to other systems 
202 and the client system 105, as shown at the bottom of Fig. 2. These notification 
transactions include, but are not limited to, confirmations of orders and shipment to 
the client system 105, which in turn notifies the customer 102. Notification 
transactions also include other system 202 notification transactions, such as 
administrative systems notification transactions and financial systems notification 
transactions. Examples of a financial system notification are notification of a order 
request to charge the order to a credit card and notification of a order request to issue 
an invoice. 
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A response to a order request flows from the provider order request 
management systems 120 through the order request servicing system 110 and the 
client system 105 to the customer 102. Both responses to order requests in real-time 
(allowing for processing and communication delays) and responses to a batch order 
request for a order request responses are communicated through the order request 
servicing system 110. An example of an information flow from an order request 
management system 120 to a customer is a change in a order status detected as a 
result of analyzing a periodic batch order request by the order request servicing 
system 1 10 for updated provider statuses. Each provider order status is 
communicated to and analyzed by the order request servicing system 1 10 to produce 
an integrated order status for the order from which the provider order originated. A 
notification of the change in the integrated order status is sent via the client system 
105 to the customer 102. The updated provider order status may result in additional 
transactions sent to order request management systems 120 and additional notification 
transactions sent to other systems 202, as shown at the bottom of Fig. 2. 

Fig. 3 shows the environment in which the order request servicing system 110 
operates in responding to a order request in the form of an order. A user management 
system 310 that resides outside the order request servicing system 110 manages a user 
database 312. The user database 312 contains information about authorized clients of 
the order request servicing system 110, including each client's relationships to its 
fulfillment partners. 

Order service 320 is the core of the order request servicing system 110 that 
serves as a central point for collecting data and processing orders. In the embodiment 
shown in Fig. 3, the order request servicing system 1 10 is an object-oriented system 
using routing objects 324 and Order request Provider Objects 326 to process orders. 

Order service 320 receives a order request in the form of an order from a client 
system 105. Order Service 320 then order requests the user management system 310 
to retrieve business relationships from the user database 3 1 2 for the client of the 
order. Business relationships include an identification of associated business rules to 
be used in fulfilling the order for the client. 

If the order request is an order, a routing object 324 determines whether the 
order should be split into portions, with one portion for each provider selected to 
provide an item included in the order. As noted above, the term "item" encompasses 
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both goods and services. The term "item" is also used herein to include multiple 
quantities of the same good or service. As used herein, an order for one computer, 
one printer, and five monitors could be interpreted several ways depending on the 
business rules and relationships of the client. The order could be interpreted as 
containing seven items, the first item being the computer, the second item being the 
printer, and the third through seventh items each being one of the five monitors. 
According to the business rules of another organization, the same order could be 
interpreted as three items, the first item being the computer, the second item being the 
printer, and the third item being the five monitors. Still another interpretation might 
be that the order contains four items, the first item being the computer, the second 
item being the printer, the third item being a subset of the five computers, and the 
fourth item being the remaining subset of the five computers. Yet another 
interpretation might be that the order includes two items, the first item comprising a 
computer system including the computer, printer, and one of the monitors, and the 
second item being the remaining four monitors. Many other permutations are 
possible depending upon the business rules and relationships of the client. 

Routing rules for selecting a fulfillment partner of a particular client are 
encapsulated in a routing object 324. The routing object 324 uses routing rules to 
select from the client's business relationships a fulfillment partner to provide each 
item ordered. Each selected fulfillment partner is called a provider. Routing objects 
324 communicate the selected providers for the order to order service 320 by 
producing a fulfillment plan which pairs each item in the order with a selected 
provider. 

Based upon the fulfillment plan, order service 320 creates a provider order for 
each provider selected to fulfill the order. Each provider order includes at least one 
item to be provided by the provider. An integration interface 330 is used to ensure 
that each provider order 440 corresponds to the corresponding provider's order 
request management system 120 format. 

An integration interface 330 consists of an interface, which specifies the types 
of transactions that are necessary to communicate with a type of multi-source order 
request servicing system such as order request management system 120, and an 
implementation of the interface, which provides the procedures and data structures 
necessary for communicating with a particular order request management system 120. 
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An integration interface 330 provides the information necessary to reformat a order 
request such as an order from a format of the order request servicing system 1 10 to a 
format of the order request management system 120. The term "format" is used 
herein to describe the structure of the data and the procedures used to transmit and 
receive data so that the data can be understood by the receiving system. 

In the embodiment described above for Figs. 3 and 4, the interface 
implementation includes integration objects that translate data from the order request 
servicing system 110 format to the order request management system 120 format. An 
integration object transmits a transaction to the order request management system 
120. Integration objects maybe implemented as application program interfaces 
(APIs), including Java classes. An example of an integration interface 330 
implementation is an Order request Provider Object 326, which is used to construct 
and transmit provider orders 440 that correspond to the selected provider's order 
request management system 120 format. 

Order service 320 stores a copy the provider order in order database 322, 
including provider information and a provider order status. Other embodiments of a 
multi-source order request servicing system may include other types of databases to 
store order requests and order request responses. Each provider order record is linked 
to the at least one order record for the order from which the provider order originates. 
Routing object 324 routes the provider order to an Order request Provider Object 326, 
which in turn transmits the provider order to the provider's order request management 
system 120. 

An Order request Provider Object 326 is a type of integration object. Each 
Order request Provider Object 326 represents a provider and defines procedures for 
transmitting order requests to the provider's order request management system 120 
and receiving order request responses from the provider's order request management 
system 120. An Order request Provider Object 326 must know how to validate an 
order from a client for a selected order request management system 120, transmit a 
provider order to the provider's order request management system 120, and obtain an 
provider order status from the provider's order request management system 120. 

Fig. 4 shows an information flow resulting from receiving a order request in 
the form of an order through an embodiment of a multi-source order request servicing 
system, the order request servicing system 110 shown in Fig. 3. A client system 105 
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transmits an order 410 from a customer 102 to the order request servicing system 110. 
The order request servicing system 110 receives the order 410 and uses a routing 
object 324 to determine whether to split the order into portions according to the 
different items ordered. The routing object 324 selects a provider for each item from 
5 the business relationships retrieved by the user management system 310 and 

associated routing rules. The routing object 324 produces a fulfillment plan 430 for 
the order indicating a selected provider for each item ordered. Provider orders 440 
are created by the routing object 324 for each provider selected. Order request 
Provider Objects 326 transmit the provider orders 440 to the providers' order request 
10 management systems 120. Each provider order contains only the items that the 
corresponding provider is to supply. 

Fig. 5 is a detailed block diagram of one embodiment of a multi-source order 
request servicing system, the order request servicing system 110. Customers 102 
place a order request using a client system 105, which provides a client interface 104. 
^ 15 Types of client interfaces 104 include but are not limited to kiosks, computer systems 
yt accessing a web storefront, and computer systems communicating with the order 

J " request servicing system 110 via a network interface. Order request servicing systems 

110 transmit transactions to order request management systems 120 and other systems 
202. The order request servicing system 110 contains a number of modules, common 
if 20 to multi-source order request servicing systems, which will be discussed in further 

IssJ 

Q detail below. 

The detailed diagram for order request servicing system 1 shows several 
information flows through the order request servicing system 110. In the Receive 
Order request 510 module, the order request servicing system 110 receives a order 
25 request from a client system 105. Components of order service 320 of Fig. 3 are 
included in the Receive Order request 5 TO module. 

The order request servicing system 1 10 can receive data via a network 
interface such as an electronic data interchange (EDI) gateway or an extensible 
markup language (XML) gateway. The EDI gateway used by order request servicing 
30 system 110 can receive data by electronic data interchange, by file transfer protocol, 
by Internet protocol, and from value-added networks. The XML gateway can receive 
data by hypertext transfer protocol (HTTP) from markup languages, including 
hypertext markup language (HTML) and extended markup languages such as XML. 
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If the order request is an order, at least one record of the order is created and 
stored in order database 322. 

In the Analyze Order request/Response and Create Necessary Transactions 
module 520, the order request servicing system 110 determines the source and type of 
order request, determines the necessary transactions to respond to the order request 
and to notify other systems 202 of the order request, and creates those transactions. 
The Analyze Order request/Response and Create Necessary Transactions module 520 
may use business rules 522, business relationship data 524, routing rules 526, and 
routing data 528 to determine the necessary transactions and the appropriate systems 
to receive transactions for the order request. In the object-oriented embodiment of the 
order request servicing system 110 shown in Figs. 3 and 4, the order request servicing 
system 110 uses routing objects 324 and business relationship objects 314 to generate 
transactions. The Analyze Order request/Response and Create Necessary 
Transactions module 520 also structures the transactions in a format corresponding to 
the receiving systems. In the object-oriented embodiment of the order request 
servicing system 110 shown in Figs. 3 and 4, the order request servicing system 110 
uses Order request Provider Objects 326 to ensure that the transactions correspond to 
the format of the order request management systems 120. 

Transactions created for an order by the Analyze Order request/Response and 
Create Necessary Transactions module 520 are sent to the appropriate systems by the 
Transmit Transactions to Order request management systems module 530 and the 
Transmit Transactions to Other Systems module 560. As noted on the diagram, each 
transaction directed to an order request management system 120 must pass through an 
integration interface 330 to ensure that the order request management system 120 can 
process the transaction. Similarly, each transaction sent to an other system must pass 
through an other systems interface 565 to ensure that the transaction corresponds to 
the receiving system. The Analyze Order request/Response and Create Necessary 
Transactions module 520 ensures that each transaction corresponds to the receiving 
systems when the transaction is created. The Transmit Transactions to Order request 
management systems module 530 uses the Order request Provider Objects 326 
described above to transmit provider orders to the order request management systems 
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Information also flows from the order request management systems 120 
through the order request servicing system 1 10 to the client system 105 to the 
customer. Receive Response module 540 receives order request responses, such as 
provider order statuses, from order request management systems 120. 

The Analyze Order request/Response and Create Necessary Transactions 
module 520 analyzes the order request responses from the order request management 
systems 120. The order request response is analyzed in a manner similar to that 
described for analyzing order requests from client systems 105. If the order request 
response is a provider order status, the order request servicing system 110 may 
integrate all provider order statuses for the order and provide an updated order status 
to the client system 105 to be communicated to the customer 102. The Analyze Order 
request/Response and Create Necessary Transactions module 520 also structures each 
transaction in a format corresponding to the system to receive the information. 

Fig. 5 also illustrates the flexibility of the order request servicing system 110. 
As described above, the order request servicing system 110 communicates with a 
variety of diverse order request management systems 120, which meets a long- felt 
need to communicate with multiple fulfillment partners' order request management 
systems 120 to obtain current and accurate order status information. 

In addition, the order request servicing system 110 can recursively call itself to 
fill an order. For example, if a division of an order servicing organization fills the 
organization's own orders, one of the order request management systems 120 called 
by the order request servicing system 110 includes the order request servicing system 
110 itself. The recursive call from order request servicing system 1 to itself is shown 
by arrow 532 in Fig. 5. 

Finally, the order request servicing system 1 10 can interface with a provider's 
order request management system 120 that is also an order request servicing system 
1 10, as shown by the order request servicing system 2 and order request servicing 
system N modules in Fig. 5. The ability to chain multiple order request servicing 
systems 110 together enables a business to model its complex supply chains and to 
present a virtual direct sales model to its customers. In the embodiment shown in Fig. 
5, each of order request servicing system 2 and order request servicing system N 
serves a spoke in the order servicing network 130 with order request servicing system 
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1 as a hub. In addition, each of order request servicing system 2 and order request 
servicing system N serves as a hub in its own order servicing network 130. 

Fig. 6 shows a flowchart of the operation of the Analyze Order 
request/Response and Create Necessary Transactions module 520. The types of order 
requests and responses shown in Fig. 6 are for illustrative purposes only, as the order 
request servicing system 110 can analyze many other types of order requests and 
responses. 

Step 610, Determine Source of Information, includes determining the source 
of information received by the Receive Order request 510 module and the Receive 
Response 540 module. In step 612, the order request servicing system 110 determines 
whether the source of the information is the client. If the source is not the client, the 
information received may be a response and order request servicing system 110 
proceeds to step 614. If the source is the client, the information received is a order 
request and order request servicing system 110 proceeds to step 620. 

In step 620, order request servicing system 110 has received a order request. 
Order request servicing system 110 determines whether the order request is an order. 
If the order request is not an order, order request servicing system 110 proceeds to 
step 630. If the order request is an order, order request servicing system 110 proceeds 
to step 622. 

In step 622, order request servicing system 110 analyzes the order and creates 
the necessary transactions to fulfill the order. Step 622 will be discussed in further 
detail below. After completing step 622, the order request servicing system 1 10 
proceeds to step 660. 

Returning to step 630, if the order request is not an order, the order request 
servicing system 110 determines in step 630 whether the order request is a order 
request . for order status. If the information is not a order request for order status, the 
order request servicing system 110 proceeds to step 635 to determine whether the 
information represents another valid type of client order request. If so, the order 
processing system 110 proceeds to step 637 to process the information, and then 
proceeds to step 660. If not, order request servicing system proceeds to step 655 to 
perform error handling and then proceeds to step 660. 

Returning to step 630, if the order request is a valid order request for order 
status, the order request servicing system 110 proceeds to step 632 to analyze the 
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order request and create necessary transactions to fulfill the order request. Step 632 
will be discussed in more detail below. From step 632, the order request servicing 
system 110 proceeds to step 634 to mark the order records stored in order database 
322 with a notation that a order request for order status is outstanding. From step 634, 
the order request servicing system 110 proceeds to step 660. The order request 
servicing system 110 then waits to receive the provider order statuses from the 
provider order request management systems 120. 

Returning to step 614, if the source of the information is not an order request 
management system 120, the order request servicing system 110 proceeds to step 616 
to determine whether the source is another valid source of information. Step 616 and 
step 650 illustrate that the order request servicing system 110 may process 
information from sources in addition to the client systems 105 and order request 
management systems 120. From step 650, order request servicing system 110 
proceeds to step 660. If the source is not valid, order request servicing system 
proceeds to step 655 to perform error handling and then proceeds to step 660. 

In step 614, if the source of the information received is an order request 
management system 120, the information received is a order request response. Order 
request servicing system 110 proceeds to step 640 to determine whether the response 
is a provider order status. If the order request response is not a provider order status, 
the order request servicing system 110 proceeds to step 645 to analyze whether the 
response is another valid type of response and to step 647 to process the other 
response from the order request management system 120. Step 645 and step 647 
illustrate that the order request servicing system 110 may process other types of 
responses from order request management systems 120 in addition to provider order 
statuses. From step 647, order request servicing system 110 proceeds to step 660. If 
the information received is not a valid response, order request servicing system 
proceeds to step 655 to perform error handling and then proceeds to step 660. 

Returning to step 640, if the response is a provider order status, in step 642 the 
order request servicing system 110 analyzes the provider order status and creates the 
necessary transactions to correspond to the order request response. For instance, the 
order request servicing system 110 may determine that it is desirable to order request 
provider order statuses for each provider order related to the order to provide an 
updated order status to the client system 105. Step 642 will be discussed in more 
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detail below. Upon completing step 642, the order request servicing system 110 
proceeds to step 660. 

In step 655, order request servicing system 110 has received information that 
is not a valid order request or response. Order request servicing system 110 performs 
error handling and then proceeds to step 660. 

From steps 634, 637, 642, and 647, the order request servicing system 110 
proceeds to step 660. In step 660, the order request servicing system 110 has 
completed processing of the Analyze Order request/Response and Create Necessary 
Transactions module 520 and continues to module 530 of Fig. 5 to transmit the 
created transactions to the corresponding order request management systems 120. 
Order request servicing system 110 may also continue to module 560 to transmit 
transactions to other systems 202. 

Fig. 7 shows a flowchart of the operation of the Analyze Order step 622 of 
Fig. 6. In step 710, the order request servicing system 110 verifies the client's 
credentials to ensure that the client has proper authority to order items using the order 
request servicing system 110. In the embodiment of the order request servicing 
system 110 shown in Figs. 3 and 4, order service 320 calls the user management 
system 310 to verify the client's credentials. In step 712, the order service 320 creates 
one or more records to represent the order 410 in order database 322. In step 714, the 
order service 320 order requests relationship information for the client from user 
management system 310. The relationship information is used to select the 
fulfillment partners to provide the items in the client's order. In step 716, the routing 
object 324 selects providers for each item ordered by the client from the relationships 
for the client retrieved in step 714. 

In step 718, the routing object 324 generates a fulfillment plan 430 for the 
order 410, with each item of the order related to a provider fulfillment partner. In step 
720, order service 320 creates transactions in the form of a provider order 440 for 
each order request management system 120 to fulfill one or more items of the order. 
Each provider order 440 must correspond to the order format required by the 
corresponding provider's order request management system 120. A routing object 
324 uses an Order request Provider Object 326 to translate data from the order request 
servicing system 110 format to the selected order request management system 120 
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format. The Order request Provider Object 326 transmits the provider order 410 to 
the corresponding provider's order request management system 120. 

In step 722, the order request servicing system 110 determines whether other 
system 202 notification transactions are needed in addition to the provider order. If 
other system 202 notification transactions are not needed in step 722, the order 
request servicing system 110 proceeds to step 730 to continue processing. If other 
system 202 notification transactions are needed, order request servicing system 110 
proceeds to step 724 to create the notification transactions for the corresponding other 
systems 202. For example, billing information might be provided to a financial 
system for invoicing immediately upon generating the fulfillment plan. In the object- 
oriented embodiment described above, notification objects are created. Order request 
servicing system 110 then proceeds to step 730, which completes processing of step 
622, Analyze Order and Create Necessary Transactions. The order request servicing 
system 110 has also completed module 520, Analyze Order request/Response and 
Create Necessary Transactions. Order request servicing system 110 may then use 
module 550 of Fig. 5 to transmit the created transactions to the client systems 105. 
Order request servicing system may use module 560 to transmit the created 
transactions to the other systems 202. 

Fig. 8 shows a flowchart of the operation of the Analyze Order 
request/Response for Order Status 632 module. The order request servicing system 
110 may order request updated provider order status information from the order 
request management systems 120 in real-time (allowing for transmission and 
processing delays). For example, a real-time query might be issued in response to a 
customer order request for an order status. Each order request management system 
120 will provide a provider order status in response to a order request for order status. 
The order request servicing system 1 10 determines an overall order status from the 
related provider order statuses, which it conveys to the order requesting client system 
105, which in turn conveys the order status to the customer. 

The order request servicing system 110 may also receive provider order 
statuses from its own batch order request for order status. The order request servicing 
system 110 determines the effect of the updated provider order statuses on the related 
order statuses. The order request servicing system 110 notifies the client system 105 
of changes in order status but may create no transactions if the order status has not 
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changed. In response to a notification transaction, the client system 105 notifies the 
customer. 

The customer provides an order number in the order request for order status. 
In step 810, order service 320 verifies the order number supplied. In step 820, the 
5 order service 320 retrieves the provider order 440 records from order database 322 
that are associated with the order number. In step 830, order service 320 prepares a 
transaction in the form of a order request for provider order status to each provider's 
order request management system 120. 

In step 840, the order request servicing system 110 determines whether other 
10 system 202 notification transactions are needed in addition to the order requests for 
provider order statuses. If other system 202 notification transactions are not needed in 
step 840, the order request servicing system 110 proceeds to step 860 to exit the 
analysis of the order request for order status and return to module 530 of Fig. 5, 
r; Transmit Transactions to Order request management systems. If other system 202 

U3 15 notification transactions are needed, order request servicing system 110 proceeds to 

SJ 

jri step 850 to create the notification transactions for the corresponding other systems 

y 5 202. Order request servicing system 110 then proceeds to step 860, which completes 

s ~ 

D step 632, Analyze Order request/Response for Order Status and Create Necessary 

q Transactions. The order request servicing system 110 has also completed module 

y 20 520, the Analyze Order request/Response and Create Necessary Transactions, and 

Q 

p uses module 550 of Fig. 5 to transmit the created transactions to the order request 

management systems 120 and other systems 202. A response to the order request will 
be provided by the Analyze Provider Order Status 642 step. 

Fig. 9 shows a flowchart of the Analyze Provider Order Status 642 step. The 
25 order request servicing system 110 has received a response in the form of a provider 
order status from an order request management system 1 20. A provider order status 
includes a response to the following types of order requests: a order request for order 
status from a customer, and a batch order request to update order status which is run 
periodically. 

30 In step 910, the order request servicing system 110 retrieves from order 

database 322 the provider orders for which a provider order status has been received, 
in addition to all other provider order records for the related order. Order request 
servicing system 110 then proceeds to step 920 to update the corresponding provider 
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order records with the provider order status received. Order request servicing system 
110 then proceeds to step 930 to determine the order status for the order from the 
provider order records associated with the order. The provider order statuses for the 
provider orders making up the order are integrated to provide an overall order status. 

In step 940, order request servicing system 110 determines whether the order 
has an outstanding order request for order status. If the order has an outstanding a 
order request for order status, order request servicing system 110 proceeds to step 
950. If the order does not have an outstanding a order request for an order status, 
order request servicing system 110 proceeds to step 942. 

In step 942, no order request for an order status is outstanding. If there is no 
change in order status, order request servicing system 110 does not notify the client of 
the receipt of the updated provider order status because the overall order status is 
unaffected. Rather, order request servicing system 110 proceeds to step 940 to 
determine if other system 202 notification transactions are needed. 

In step 942, if there has been a change in order status, order request servicing 
system 110 proceeds to step 960. 

Returning to step 940, if order request servicing system 110 has determined 
that a order request for order status is outstanding, order request servicing system 110 
proceeds to step 950. In step 950, order request servicing system 110 determines 
whether all provider order statuses for the order have been received. If all provider 
order statuses for the order have not been received, the order request servicing system 
110 proceeds to step 970 to wait for other provider order statuses to arrive. If all 
provider order statuses for the order have been received, the order request servicing 
system 110 proceeds to step 960. 

In step 960, either a order request for order status was outstanding and all 
provider order status responses have been received, or an order request management 
system 120 has sent an updated provider order status that affects an overall order 
status. In step 960, the order request servicing system 110 creates a notification 
transaction containing the order status to be sent to the client system 105. 

In step 970, the order request servicing system 110 determines whether other 
system 202 notification transactions are needed in addition to the notification of the 
client system 105 of a changed or updated order status. If other system 202 
notification transactions are needed, order request servicing system 110 proceeds to 
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step 980 to create the notification transactions for the corresponding other systems 
202. If other system 202 notification transactions are not needed in step 970, the 
order request servicing system 110 proceeds to step 990 to complete the analysis of 
the order request for order status. 

In step 990, the order request servicing system 110 has completed step 642, 
the Analyze Provider Order Status step. The order request servicing system 110 has 
also completed module 520, the Analyze Order request/Response and Create 
Necessary Transactions, and uses module 550 of Fig. 5, Send Transactions to Client 
System, to transmit the order status to the client systems 105. 

While the invention has been described with respect to the embodiments and 
variations set forth above, these embodiments and variations are illustrative and the 
invention is not to be considered limited in scope to these embodiments and 
variations. For example, in another embodiment, the order request servicing system 
may be implemented in a software environment that does not use the object-oriented 
paradigm. Accordingly, various other embodiments and modifications and 
improvements not described herein may be within the spirit and scope of the present 
invention. 
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